There are a significant number of wireless technologies in the marketplace today. One standard for short range wireless technology is called Bluetooth. Bluetooth is a Radio Frequency (RF) specification for short-range, point-to-multipoint voice and data transfer. Bluetooth can transmit through solid, non-metal objects. Its nominal link range is from 10 cm to 10 m, but the range can be extended to 100 m by increasing the transmit power. It is based on a low-cost, short-range radio link, and facilitates ad hoc connections for stationary and mobile communication environments.
The Bluetooth wireless technology allows users to make connections between communication devices such as mobile phones and desktop and notebook computers. Finding and communicating with services in these environments is becoming increasingly important due to the continued growth in wireless technologies as seen by the proliferation of mobile computing devices and also due to the merging of wireless technologies and computer technologies. These services can include basic services such as printing, faxing, paging, etc., more complex services such as video conferencing and teleconferencing, and any other type of service that a service provider may provide.
The Bluetooth SIG (Special Interest Group) specifies protocols that ensure interoperability between various devices. One of these protocols is the Logical Link Control and Adaptation Protocol (L2CAP). L2CAP enables multiple protocols and applications to coexist over a single Bluetooth RF connection. L2CAP provides connection-oriented and connectionless-data services to higher level protocols with protocol multiplexing capability, packet segmentation and reassembly operation, and the conveying of quality of service information.
Configuring a L2CAP channel involves an iterative negotiation process between two peer L2CAP entities that is quite cumbersome and prone to error. The negotiation process starts when one of the peers sends a configuration request to the other peer. The configuration request contains the requesting peer's desired settings for connection parameters. The receiving peer responds to the configuration request with a configuration response. The response informs the requesting peer which settings have been accepted and which settings have been rejected. If a setting has been rejected, the setting the receiving peer will accept is included in the response. The requesting peer determines what settings the receiving peer has accepted and has rejected. The requesting peer sends another configuration request with its choice of parameters for the settings that haven't been accepted. This configuration process continues until either all settings have been negotiated or one of the peers drops the channel.
Once a channel has been established, either peer may reconfigure the channel. This requires the peers to stop sending data (i.e., stop reading and writing) and renegotiate the channel settings using the same process used in configuring the channel. The configuration and reconfiguration processes require the peer to maintain state of the channel, handle errors, and handle the iterative negotiations. As a result, the complexity of each node (e.g., application, object, module, etc.) using a L2CAP channel increases due to the increase in code and the reliability of the node decreases.